home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Loadstar 128 #32
/
q32side1.d64
/
t.lil red 2
< prev
next >
Wrap
Text File
|
2022-08-30
|
15KB
|
277 lines
LITTLE RED READER Version 2.00 (March 8, 1994)
MS-DOS file reader/writer for the C128 and 1571/81/FD drives
Program and Text by Craig Bruce (csbruce@neumann.uwaterloo.ca)
Interface Changed by Fender Tucker (May 8, 1996)
2.3. COPYING MS-DOS TO CBM-DOS
When you enter copy mode, the screen will clear and the name of each
selected file is displayed as it is being copied. If an error is
encountered on either the MS-DOS or CBM-DOS drive during copying, an error
message will be displayed and copying will continue (after you press a key
for MS-DOS errors).
To generate a CBM-DOS filename from an MS-DOS filename, the eight filename
characters are taken (including spaces) and a dot (.) and the three
characters of the extension are appended. Then, all spaces are removed,
and if the name ends with a dot (.) character, then that dot character is
removed as well. I think this is fairly reasonable.
If there already is a file with the same filename on the CBM-DOS disk, then
you will be prompted if you want to overwrite the file or not. Entering an
"n" will abort the copying of that file and go on to the next file, and
entering a "y" (or anything else) will cause the CBM-DOS file to be
"scratched" and then re-written.
The physical copying of the file is done completely in machine language and
nothing is indicated on the screen while this is happening, but you can
follow things by looking at das blinkin lichtes and listening for clicks
and grinds. You will probably be surprised by the MS-DOS file reading speed
(I mean in a good way). The disk data is read in whole tracks and cached
in memory and the directory information and the FAT are retained in memory
as well. The result is that minimal time is spent reading disk data, and
no costly seeks are required for opening a new MS-DOS file. A result is
that small files are copied one after another very quickly. You will have
to wait, however, on the relatively slow standard kernel/Commodore-DOS file
writing.
A few changes had to be made to the program to accomodate the RAMDOS
program. RAMDOS uses memory from $2300 to $3FFF of RAM0, which is not
really a good place for a device driver, and it uses some of the zero-page
locations that I wanted to use. But, difficulties were overcome. The
importance of RAMDOS compatibility is that if you only have one disk drive
but you have an REU, you can use RAMDOS to store the MS-DOS files
temporarily. If you only have one disk drive and no REU, you are SOL (Out
of Luck) unless you can get a RamDisk-type program for an unexpanded 128.
The RAMDOS program is available from FTP site "ccosun.caltech.edu" in file
"/pub/rknop/util128/ramdosii.sfx". One note I found out about RAMDOS: you
cannot use a
DOPEN#1,(CF$),U(CD),W
with it like you are supposed to be able to; you have to use a
DOPEN#1,(CF$+",W"),U(CD)
Here is a table of copying speeds for copying from 1571s and 1581s with ASC
and BIN translation modes. All figures are in bytes/second. These results
were obtained from copying a 127,280 byte text file (the text of C= Hacking
Issue #3).
FROM TO: "null" RAMLink RAMDOS JD1581 JD1571
------- ------ ------- ------ ------ ------
81-bin 5772 3441 2146 n/a 644
81-asc 5772 3434 2164 n/a 661
71-bin 4323 2991 1949 1821 n/a
71-asc 4323 2982 1962 1847 n/a
The "null" device is that "0" CBM-DOS device number, and a couple of
entries are "n/a" since I only have one 1571 and one 1581. Note that my 71
and 81 are JiffyDOS-ified, so the performance of a stock 71/81 will be
poorer. JiffyDOS gives about a 2x performance improvement for the standard
file accessing calls (open, close, chrin, chrout). RAMDOS doesn't seem to
be as snappy as you might think.
The "null" figures are quite impressive, but the raw sector reading speed
without the overhead of mucking around with file organization is 6700
bytes/sec for a 1581 and 4600 B/s for a 71. The reason that the 1571
operates so quickly is that I use a sector interleave of 4 (which is
optimal) for reading the tracks. I think that other MS-DOS file copier
program uses an interleave of 1 (which is not optimal). I lose some of the
raw performance because I copy the file data internally once before
outputting it (to simplify some of the code).
In a couple of places you will notice that ASC translation gives slightly
better or slightly worse performance than BIN. This is because although
slightly more work is required to translate the characters, slightly fewer
characters will have to be written to the CBM-DOS file, since PETSCII uses
only CR where MS-DOS ASCII uses CR and LF to represent end-of-line.
Translation is done by using a table (that you can change if you wish).
Many entries in this table contain a value of zero, which means that no
character will be output on translation. Most of the control characters
and all of the characters of value 128 (0x80) or greater are thrown away on
being translated. The table is set up so that CR characters are thrown
away and the LF character is translated to a CBM-DOS CR character. Thus,
both MS-DOS ASCII files and UNIX ASCII files can be translated correctly.
2.4. COMMODORE-DOS MENU
The Commodore-DOS menu, which displays the names of the Commodore files
selected for various operations, looks and works pretty much the same as
the MS-DOS menu:
CBMDOS MS=10:1581 CBM=8 FREE=3211476
NUM S TRN FILENAME T LENGTH
--- - --- ---------------- - ------
1 * BIN LRR-128 P 9876
2 ASC COM-HACKING-005 S 175412
D - Directory M - MS Device F - CBM Device C - Copy Q=Quit
T - Toggle All R - Remove X - CBM Copy / - Switch +/- Page
You'll notice, however, that the filetype field ("T" here) is moved and is
unchangable. Also, the file lengths are not exact; they are reported as
the block count of the file multiplied by 254. This menu is not maintained
for files being copied to the CBM-DOS disk from an MS-DOS disk. You'll
have to re-execute the Directory instruction to get an updated listing.
The "D" (directory) command has local effect when in this menu. The
Commodore-DOS directory will be loaded from the current CBM device number.
Note that in order for this to work, the CBM device must be number eight or
greater (a disk drive). Originally, the subroutine for this command was
written using only GET#'s from the disk and was very slow. It was
modified, however, to call a machine language subroutine to read the
information for a directory entry from the directory listing, and hence the
subroutine now operates at a tolerable speed.
The "C" (copy) command also has a different meaning when in this menu. It
means to copy the selected CBM files to the MS-DOS disk. See details
below.
The copy CBM files ("X") command is used to copy the files in the CBM-DOS
menu to another CBM-DOS disk unit. Select the files you want to copy and
then press X. You will then be asked what device number you want to copy
the files to. The device can be another disk drive or any other device
(except the keyboard). Using device number 0 does not mean the "null"
device as it does with copying MS-DOS to CBM. If you are copying to a disk
device and the file already exists, then you will be asked if you wish to
overwrite the file. You cannot copy to the same disk unit. Also, all
files are copied in binary mode (regardless of what translation you have
selected for a file).
The copy CBM files command was included since all of the low-level gear
needed to implement it (specifically "commieIn" and "commieOut" below) was
also required by other functions. This command can be very convenient when
working with RAMDOS. For example, if you only had a 1571 as device 8 but
you have a RAM expander and have installed RAMDOS as device 9, then you
would copy MS-DOS files to RAMDOS using the MS-DOS menu, and then you would
go to the Commodore-DOS menu ("/"), read the directory, select all files,
insert an Commodore-DOS disk